home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-cat-ftpsec-00.txt
< prev
next >
Wrap
Text File
|
1993-04-06
|
35KB
|
809 lines
Network Working Group Internet Engineering Task Force
Internet-Draft Common Authentication Technology Working Group
Updates: RFC 959 S. J. Lunt
Bellcore
April 1993
FTP Security Extensions
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Distribution of this memo is unlimited. Please send comments to the
<ftp-wg@tgv.com> mailing list.
1. Description
This document defines extensions to the FTP specification RFC959,
"FILE TRANSFER PROTOCOL (FTP)" (October 1985), which provide strong
authentication, integrity, and confidentiality on both the control
and data channels with the introduction of new optional commands,
replies, and file transfer encodings.
The following new optional commands are introduced in this
specification:
AUTH (Authentication Type), ADAT (Authentication Data), MIC
(Integrity Protected Command), ENC (Privacy Protected Command),
and PROT (Data Channel Protection Level).
A new class of reply types (6yz) is also introduced for protected
replies.
Expires: October 31, 1993 [Page 1]
Internet-Draft FTP Security Extensions April 1993
None of the above commands are required to be implemented, but each
is dependent on the other (except ENC, which is optional).
Note that this specification is compatible with RFC959.
2. Motivation
The File Transfer Protocol (FTP) currently defined in RFC959 and in
place on the Internet uses usernames and passwords passed in
cleartext to authenticate clients to servers (via the USER and PASS
commands). Except for services such as 'anonymous' FTP archives,
this represents a security risk whereby passwords can be stolen
through monitoring of local and wide-area networks. This either aids
potential attackers through password exposure and/or limits
accessibility of files to remote users who can or will not accept the
inherent security risk.
Aside from the problem of authenticating users in a secure manner,
there is also the problem of protecting sensitive data and/or
verifying its integrity. An attacker may be able to access valuable
or sensitive data merely by monitoring a network, or through active
means may be able to delete or modify the data being transferred so
as to corrupt its integrity. An active attacker may also initiate
spurious file transfers to and from a site of the attacker's choice,
and may invoke other commands on the server. FTP does not currently
have any provision for the encryption or verification of the
authenticity of commands, replies, or transferred data. Note that
these security services have value even to anonymous file access.
Current practice for sending files securely is generally either:
1. via FTP of files pre-encrypted under keys which are manually
distributed,
2. via electronic mail containing an encoding of a file encrypted
under keys which are manually distributed,
3. via a PEM message, or
4. via the rcp command enhanced to use Kerberos.
None of these means could be considered even a de facto standard, and
none are truly interactive. A need exists to securely transfer files
using FTP in a secure manner which is supported within the FTP
protocol in a consistent manner and which takes advantage of existing
security infrastructure and technology. Extensions are necessary to
the FTP specification if these security services are to be introduced
into the protocol in an interoperable way.
Expires: October 31, 1993 [Page 2]
Internet-Draft FTP Security Extensions April 1993
3. New FTP Commands
The following commands are optional, but dependent on each other.
They are extensions to the FTP Access Control Commands.
AUTHENTICATION TYPE (AUTH)
The argument field is a Telnet string identifying a supported
authentication mechanism. The command represents a request to
perform an authentication protocol exchange based on an
authentication mechanism identified by the argument. Currently,
only KERBEROS_V4 and GSSAPI are defined.
If the server accepts an authentication type with reply code 334,
then the client must next initiate an authentication exchange (via
the ADAT command) based on that authentication type. The goal of
the authentication exchange is to strongly authenticate the user
to the server, and to establish a security context [3] under which
protection of the control and data channels may be performed.
If the server replies with a 234 code, then the authentication
type is accepted, and no ADAT commands are required. This is
useful to indicate to the server that the password to be sent in a
subsequent PASS command is to be interpreted differently than
normal, as in the case of smart cards or other non-disclosing
password systems. Challenge information intended for human
interpretation may be contained in the reply. Such information
may also be conveyed in the text of the reply to the USER command.
If the server rejects a type (reply code 504), or any ADAT command
fails, then the client may try another authentication type by
issuing another AUTH command, or may continue by sending USER and
PASS commands. Thus, the client should request authentication
types in decreasing order of preference (i.e., strength). The
server will reject (with a 503 reply code) any AUTH or ADAT
commands sent after an authentication protocol successfully
completes.
The client should not require the server to support the AUTH
command or any particular authentication type. If either the
server does not support the AUTH command (reply code 500), or the
client and server cannot agree on an authentication type, or no
authentication exchange succeeds, then the default USER and PASS
commands must be performed.
The AUTH command will normally be the first command transmitted by
the user after the control connections are made, generally before
the USER command. However, the AUTH command may cause the control
connection to be closed by servers which require the USER command
to be the first command transmitted by the user after the control
Expires: October 31, 1993 [Page 3]
Internet-Draft FTP Security Extensions April 1993
connection is made.
Some servers will require that authentication be performed before
certain commands (including USER) will be accepted. In this case,
a 530 reply will be sent indicating that an authentication
exchange is required.
Some authentication protocols may require prior knowledge of the
remote user name (e.g., some challenge/response systems). In this
case, the USER command may be sent in advance of the AUTH command.
AUTHENTICATION DATA (ADAT)
The argument field is a Telnet string representing a base 64
encoded authentication data (see the definition of the MIC command
for a description of base 64 encoding). The data is specific to
the authentication protocol specified by a previous AUTH command.
The ADAT command, and the associated replies, allow the client and
server to conduct an arbitrary authentication protocol. The
client will send authentication data to the server via the ADAT
command, and the server will send authentication back to the
client by including "ADAT=string" in the reply, where string is
also a Telnet string representing base 64 encoded authentication
data. The server will reply 501 if the string could not be base
64 decoded.
If the server sends a 535 reply, then the authentication data
could not be successfully processed, and the client has not been
authenticated. The client may either try another authentication
type by sending another AUTH command, or may send USER and PASS
commands. The server will reply 503 if no AUTH command was
previously accepted.
If the server sends a 335 reply, then the authentication data was
successfully processed, but more authentication data is necessary
to complete the authentication process. In this case, the server
must include encoded authentication data in the reply. The client
must process this returned data and then issue another ADAT
command.
If the server sends a 235 reply, optionally including encoded
authentication data, then the server considers the client
authenticated. The client must process any authentication data
present in the reply.
Appendix I defines the actual protocol for KERBEROS_V4. Appendix
II defines the actual protocol for GSSAPI.
If an authentication exchange succeeds, then the client's identity
Expires: October 31, 1993 [Page 4]
Internet-Draft FTP Security Extensions April 1993
has been authenticated but not yet authorized. The client must
next invoke the USER command to identify to the server the account
(file system) for which access is requested. If the USER command
results in a 231 reply, then the client is authorized, and no
password is required. However, the client must then send the PASS
command to actually log the user in (the actual password is
ignored and should be a dummy value). If the USER command results
in a 333 reply, then the user was not authorized without a
password, and a password must be sent with the PASS command. In
this case, it is recommended that the PASS command be ENC
protected. Additional USER or PASS commands may be sent after
success of an ADAT command.
Once the client is successfully authenticated via AUTH and ADAT
commands, the rest of the data over the control channel (commands
and replies) must be protected, either with integrity (by a
cryptographic checksum) via the MIC command, or with
confidentiality (by encryption) via the ENC command. (Also see
the section on protected replies.) These two commands may be
arbitrarily intermixed. It is up to the client to decide which of
MIC and ENC commands to use, and it is up to the server when to
accept either. The server will return a 502 reply to any other
command.
Commands sent via the Telnet out-of-band signal must also be
protected. That is, if the client sends the Telnet "IP" signal
followed by the Telnet "Synch" signal, then the command sent to
the server immediately afterwards must also protected.
A requirement of all specifications for authentication exchanges
based on new authentication types is that they convey to the
caller whether encryption is supported on the resultant security
context, since it is not a requirement that the ENC command, 632
protected replies, or the Private protection level be supported.
It is also strongly suggested that per message protection services
supported by each mechanism perform message replay and out-of-
sequence detection, since no provision for these services is
explicitly made within this specification.
Since no explicit provision is made in this specification for the
negotiation of specific mechanisms for performing per message
protection services, implementors should instead utilize the token
exchange for this purpose.
INTEGRITY PROTECTED COMMAND (MIC)
The required argument is a Telnet string consisting of a base 64
encoded "safe" message produced by an authentication mechanism
specific message integrity procedure. The server will decode the
Expires: October 31, 1993 [Page 5]
Internet-Draft FTP Security Extensions April 1993
received string, verify its integrity via the authentication
mechanism specific message integrity procedure, and upon success,
interpret the resultant string as an FTP command. The user-
process need not include the Telnet end-of-line character within
the encoded command.
Base 64 encoding is the same as the Printable Encoding described
in Section 4.3.2.4 of [2] and is defined as follows.
Proceeding from left to right, the bit string resulting from the
mechanism specific protection routine is encoded into characters
which are universally representable at all sites, though not
necessarily with the same bit patterns (e.g., although the
character "E" is represented in an ASCII-based system as
hexadecimal 45 and as hexadecimal C5 in an EBCDIC-based system,
the local significance of the two representations is equivalent).
A 64-character subset of International Alphabet IA5 is used,
enabling 6 bits to be represented per printable character. (The
proposed subset of characters is represented identically in IA5
and ASCII.) The character "=" signifies a special processing
function used for padding within the printable encoding procedure.
The encoding process represents 24-bit groups of input bits as
output strings of 4 encoded characters. Proceeding from left to
right across a 24-bit input group extracted from the output of
step 3, each 6-bit group is used as an index into an array of 64
printable characters, namely "[A-Z][a-z][0-9]+/". The character
referenced by the index is placed in the output string. These
characters are selected so as to be universally representable, and
the set excludes characters with particular significance to Telnet
(e.g., "<CR>", "<LF>").
Special processing is performed if fewer than 24 bits are
available in an input group at the end of a message. A full
encoding quantum is always completed at the end of a message.
When fewer than 24 input bits are available in an input group,
zero bits are added (on the right) to form an integral number of
6-bit groups. Output character positions which are not required
to represent actual input data are set to the character "=".
Since all canonically encoded output is an integral number of
octets, only the following cases can arise: (1) the final quantum
of encoding input is an integral multiple of 24 bits; here, the
final unit of encoded output will be an integral multiple of 4
characters with no "=" padding, (2) the final quantum of encoding
input is exactly 8 bits; here, the final unit of encoded output
will be two characters followed by two "=" padding characters, or
(3) the final quantum of encoding input is exactly 16 bits; here,
the final unit of encoded output will be three characters followed
by one "=" padding character.
Expires: October 31, 1993 [Page 6]
Internet-Draft FTP Security Extensions April 1993
Implementors should keep in mind that the base 64 encodings in
ADAT, MIC, and ENC commands, and in 631 and 632 replies, may be
arbitrarily long. Thus, the entire string must be read before it
can be processed. Several successive reads on the control channel
may be necessary. It is not appropriate to for a server to reject
a command containing a base 64 encoding simply because it is too
long (assuming that the decoding is otherwise well formed in the
context in which it was sent).
The server will return a 501 reply if the argument could not be
properly base 64 decoded.
The server will return a 535 reply to any MIC command which fails
checksum, replay, sequencing, or other applicable security checks.
There are no other direct replies from MIC or ENC commands; the
resultant FTP command will generate its own replies.
In environments where the native character set is not ASCII, the
client must translate the encapsulated command to ASCII before
passing it to the protection routine, and the server must
translate the encapsulated command from ASCII after passing the
token to the protection routine.
PRIVACY PROTECTED COMMAND (ENC)
The required argument is a Telnet string consisting of a base 64
encoded "private" message produced by an authentication mechanism
specific message confidentiality procedure. The server will
decode the received string, verify its integrity via the
authentication mechanism specific message confidentiality
procedure, and upon success, interpret the resultant string as an
FTP command.
It is strongly recommended that PASS commands be sent under ENC
protection, when possible.
The server will return a 501 reply if the argument could not be
properly base 64 decoded.
The server will return a 535 reply to any ENC command which cannot
be properly decrypted, or fails checksum, replay, sequencing, or
other applicable security checks.
The server will return a 502 reply if it does not support the ENC
command. In this case, the client should retry the enclosed
command again under MIC protection.
Expires: October 31, 1993 [Page 7]
Internet-Draft FTP Security Extensions April 1993
DATA CHANNEL PROTECTION LEVEL (PROT)
The argument is a single Telnet character code specifying the data
protection level. The PROT command will be rejected and the
server will reply 504 if no previous ADAT command succeeded, or
the specified protection level is not supported. Upon success, a
200 reply will be sent by the server, indicating that the new
protection level is now in effect.
The following codes are assigned for protection levels:
C - Clear
S - Safe
P - Private
The default protection level is Safe, unless no ADAT command
succeeded, in which case the default protection level is Clear.
Thus, when an ADAT command succeeds, the protection level on the
client and server changes to Safe without the passing of a PROT
command. The Safe protection level is required to be implemented
by all authentication types, but the Private protection level is
optional.
When using the Safe protection level, all data sent over the data
channel is to be integrity protected by cryptographic checksum.
When using the Private protection level, all data sent over the
data channel is to be privacy protected by encryption. The sender
will apply protection services after all data transformations
associated with the current representation type, file structure,
and transfer mode have been performed. The data sent over the
data channel is, for the purposes of data protection, to be
treated as a byte stream. An authentication mechanism specific
data protection procedure will be employed by the sender to
protect this byte stream. The procedure should process a buffer
of bytes at a time, and send the result as a stream of bytes,
prepending each transferred buffer with a four byte length field
(most significant byte first). A minimal implementation must be
able to handle a buffer length of at least 65,536 bytes. The
receiver will read the four byte length field, and then read that
number of bytes of protected data, passing the buffer to an
authentication mechanism specific data protection procedure.
Further buffers will be similarly read and processed. Any
transformations associated with the current representation type,
file structure, and transfer mode would then be performed on the
resultant data. When using block transfer mode, the sender's
(cleartext) buffer size should be equal to the block size.
Under the Clear protection level (i.e., as defined in RFC 959),
Expires: October 31, 1993 [Page 8]
Internet-Draft FTP Security Extensions April 1993
and when in stream mode, the server indicates end of file by
closing the data connection. This is inherently unreliable, since
the client cannot determine whether the connection was closed
prematurely. Transferring files under the Safe or Private
protection level allows the server to send a positive indication
of end of file by sending a protected buffer which contains zero
bytes of cleartext data. Upon receipt of such a zero length
cleartext buffer, the recipient (client or server) should close
the data connection and consider the file transfer complete. If
the connection is closed before such a buffer is received, then
the file transfer on the client side should be aborted, and the
user should be alerted. If the server was the recipient, then it
should send a 426 reply in this case.
If any data protection services fail at any time during data
transfer, the server will send a 435 reply (along with possibly
other replies indicating the transfer itself failed).
4. New FTP Replies
All replies after a successful ADAT command must be protected. A new
reply type is introduced for this purpose, indicated by a sixth value
for the first digit of the reply code:
6yz Protected reply
The text of this reply is to be decoded and interpreted as an FTP
reply (if such decoding is successful). If the reply code is 631,
then the text of the reply is integrity protected in the same
manner as MIC commands. If the reply code is 632, then the text
of the reply is privacy protected in the same manner as ENC
commands. The security policy of the server will dictate when
such replies are to be used. The security policy of the client
will dictate whether other reply types will be accepted. As a
general rule, the server should send a 631 reply to a MIC command,
and a 632 reply to an ENC command. The server may send a
protected reply only if a previous ADAT command succeeded.
If the server for some reason cannot encode the reply, then the
unprotected reply will be sent instead. The server must not send
632 replies if the client does not support encryption (this should
be indicated by the security context). If, upon context
establishment, it is not known whether the client supports
encryption, then the server must only send a 632 reply in response
to an ENC command.
Multi-line replies are handled as follows. If the server sends a
protected reply in which the decoded reply has a hyphen ("-")
immediately following the reply code, then the server will send
Expires: October 31, 1993 [Page 9]
Internet-Draft FTP Security Extensions April 1993
the rest of the lines of text of the multi-line reply each encoded
as the first line was and each followed by the Telnet end-of-line
character. The last line of the multi-line reply will be that
line which when decoded by the receiver begins with the initial
reply code followed by a space. Note that it is the format of the
decoded reply, and not the enclosing protected reply, that
indicates a multi-line reply. A hyphen immediately following a
6xy reply code should be ignored. The server need not include the
Telnet end-of-line character within the encoded reply.
5. Command Summary
The following is a summary of the commands described above (in BNF
notation):
AUTH <SP> <auth-type> <CRLF>
ADAT <SP> <base64string> <CRLF>
MIC <SP> <base64string> <CRLF>
ENC <SP> <base64string> <CRLF>
PROT <SP> <protection-level> <CRLF>
The syntax of the above argument fields (using BNF notation where
applicable) is:
<base64string> ::= <quads> | <quads><terminal>
<quads> ::= <quad> | <quad><quads>
<quad> ::= <base64char><base64char><base64char><base64char>
<base64char> ::= ASCII A through Z
| ASCII a through z
| ASCII 0 through 9
| ASCII +
| ASCII /
<terminal> ::= <base64char><terminal1><pad><pad>
| <base64char><base64char><terminal2><pad>
<terminal1> ::= ASCII A through D
<terminal2> ::= ASCII A through P
<pad> ::= ASCII =
<auth-type> ::= <string>
<string> ::= <char> | <char><string>
<char> ::= any of the 128 ASCII characters except <CR> and <LF>
<protection-level> ::= C | S | P
The following lists the various reply codes for each new command:
AUTH
234
334
500, 501, 503, 504, 421
Expires: October 31, 1993 [Page 10]
Internet-Draft FTP Security Extensions April 1993
ADAT
235
335
500, 501, 503, 535, 421
MIC
500, 501, 535, 421
ENC
500, 501, 502, 535, 421
PROT
200
500, 501, 504, 421, 530
The following are additional reply codes for existing commands (502
is the only reply for all commands except ENC and MIC once ADAT
succeeds):
USER
231
333
STOR
435
STOU
435
RETR
435
LIST
435
NLST
435
APPE
435
6. References
[1] Reynolds, Joyce, and Postel, Jon, "File Transfer Protocol (FTP)",
RFC 959, ISI, October 1985.
[2] Linn, John, "Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encryption and Authentication Procedures", RFC
1421, February 1993.
[3] Linn, John, "Generic Security Service API (GSSAPI)", Internet
Draft, November 1992.
Security Considerations
Third party file transfers cannot be secured using these extensions,
since a security context cannot be established between two servers
Expires: October 31, 1993 [Page 11]
Internet-Draft FTP Security Extensions April 1993
using these facilities. Further work in this area is deferred.
APPENDIX I: SPECIFICATION UNDER KERBEROS VERSION 4
The authentication type (for the AUTH command) associated with
Kerberos Version 4 is KERBEROS_V4. If the server supports
KERBEROS_V4, it will respond with a 334 reply code indicating that an
ADAT command is expected next.
The client should retrieve a ticket for the Kerberos principal
"ftp.hostname@realm" by calling krb_mk_req(3) with a principal name
of "ftp", an instance equal to the canonical host name of the server
with all letters in lower case, the server's realm name, and an
arbitrary checksum. The ticket must then be base 64 encoded and sent
as the argument to an ADAT command.
The server must base 64 decode the argument to the ADAT command and
pass the result to krb_rd_req(3). The server must add one to the
checksum from the authenticator and encrypt it using krb_mk_priv(3),
then base 64 encode the result. Upon success, the server must reply
to the client with a 235 code and include "ADAT=base64string" in the
text of the reply. Upon failure, the server will reply 535.
Upon receipt of the 235 reply from the server, the client must parse
the text of the reply for the base 64 encoded data, decode it, and
pass the result to krb_rd_priv(3). The client should consider the
server authenticated if the resultant checksum is equal to one plus
the value previously sent.
The procedure associated with integrity protected MIC commands,
replies, and Safe file transfers is:
krb_mk_safe(3) for the sender
krb_rd_safe(3) for the receiver
The procedure associated with privacy protected ENC commands,
replies, and Private file transfers is:
krb_mk_priv(3) for the sender
krb_rd_priv(3) for the receiver
Note that this specification for KERBEROS_V4 contains no provision
for negotiating alternate means for integrity and confidentiality
routines. Also, note that the ADAT exchange does not convey whether
the peer supports confidentiality services.
APPENDIX II: SPECIFICATION UNDER THE GSSAPI
The authentication type (for the AUTH command) associated with all
Expires: October 31, 1993 [Page 12]
Internet-Draft FTP Security Extensions April 1993
mechanisms employing the GSSAPI is GSSAPI. If the server supports an
authentication mechanism employing the GSSAPI, it will respond with a
334 reply code indicating that an ADAT command is expected next.
The client should begin the authentication exchange by calling
GSS_Init_Sec_Context, passing in NULL for claimant_cred_handle to get
the default credentials for the user (this is to avoid dependencies
on names for particular mechanisms), 0 for input_context_handle
(initially), NULL for mech_type (indicating "use default mechanism
type"), and a targ_name of "ftp/hostname" where "hostname" is the
canonical host name of the server with all letters in lower case.
The output_token must then be base 64 encoded and sent to the server
as the argument to an ADAT command. If GSS_Init_Sec_Context returns
GSS_CONTINUE_NEEDED, then the client should expect a token to be
returned in the reply to the ADAT command. This token should
subsequently be passed to another call to GSS_Init_Sec_Context. In
this case, if GSS_Init_Sec_Context returns no output_token, then the
reply code from the server for the previous ADAT command should have
been 235. If GSS_Init_Sec_Context returns GSS_COMPLETE, then no
further tokens should be expected from the server, and the client
should consider the server authenticated.
The server must base 64 decode the argument to the ADAT command and
pass the resultant token to GSS_Accept_Sec_Context as input_token,
setting acceptor_cred_handle to NULL (for "use default credentials"),
and 0 for input_context_handle (initially). If an output_token is
returned, it should be base 64 encoded and returned to the client by
including "ADAT=base64string" in the text of the reply. If
GSS_Accept_Sec_Context returns GSS_COMPLETE, the reply code should be
235, and the server should consider the client authenticated. If
GSS_Accept_Sec_Context returns GSS_CONTINUE_NEEDED, the reply code
should be 335. Otherwise, the reply code should be 535.
The procedure associated with integrity protected MIC commands,
replies, and Safe file transfers is:
GSS_Safe for the sender
GSS_Verify for the receiver
The procedure associated with privacy protected ENC commands,
replies, and Private file transfers is:
GSS_Seal for the sender
GSS_Unseal for the receiver
Both the client and server should inspect the value of conf_avail to
determine whether the peer supports confidentiality services.
Author's Address:
Expires: October 31, 1993 [Page 13]
Internet-Draft FTP Security Extensions April 1993
Steven J. Lunt, Editor
Bellcore
RRC-1L213
444 Hoes Lane
Piscataway, NJ 08854
Phone: (908) 699-4244
EMail: lunt@bellcore.com
Mailing List: ftp-wg@tgv.com
Chair's Address:
The working group can be contacted via the current chair:
Sam Sjogren
TGV, Inc.
603 Mission St.
Santa Cruz, CA 95060
Phone: (408) 427-4366
EMail: sjogren@tgv.com
Editor's Notes:
This is implemented and working for Kerberos V4 on SunOS 4.1.2 using
SunOS source for ftp and ftpd, and also the BSD Reno source for ftp
and ftpd.
YET TO BE DONE:
1. The client may fail when processing the ADAT data from a 235
reply, in which case the server thinks things are OK, but the
client thinks otherwise. Unclear how to proceed at that point,
other than to drop the connection.
2. New state diagrams might need to be drawn for how the AUTH,
ADAT, USER, and PASS commands now flow.
Expires: October 31, 1993 [Page 14]